关于 npm audit 以及 npm audit fix 的修复策略了解 |
您所在的位置：网站首页 › breaking bad的意思 › 关于 npm audit 以及 npm audit fix 的修复策略了解 |
关于 npm audit 以及 npm audit fix 的修复策略了解
|
什么是 npm audit
npm audit 是npm 6 新增的一个命令,可以允许开发人员分析复杂的代码并查明特定的漏洞。 该命令会在项目中更新或者下载新的依赖包之后自动运行，如果你在项目中使用了具有已知安全问题的依赖，就收到官方的警告通知。 npm audit需要包package.json和package-lock.json文件。它是通过分析 package-lock.json 文件，继而扫描我们的包分析是否包含漏洞的。 npm audit 返回的漏洞数据来源于 Github Advisory Database 。 npm官方文档(npm-audit) 使用 npm auditnpm 源下，执行 npm audit，如果有已知漏洞，则会展示该漏洞的信息
首先我们已知，npm audit需要包package.json和package-lock.json文件。它是通过分析 package-lock.json 文件，继而扫描我们的包分析是否包含漏洞的。在使用这个命令的时候，可能有些同学会发现自己终端的 npm 命令不包含 npm audit 这条命令，产生这个问题的原因我们来探究一下。 是否和 npm 源有关？首先，在 npm 官方源下，是可以运行 npm audit的，如果切换的 cnpm 源下，就无法调用了。 如上图，在 cnpm 源下，不支持 npm audit。 那么是什么原因导致的呢 关于这个问题，我们可以自己创建一个私有源，看看有没有这个命令。 创建私有源，可以看看这个工具--verdaccio。verdaccio 可以用于搭建一个私有仓库。具体步骤本文就不细说了，有需要的小伙伴可以看官方文档或者查阅其他笔者的文章。 接下来切入正题，假设我本地已经使用 verdaccio 搭建好了一个私有源，然后我们打开它的配置文件 config.yarm 看看 可以看到在配置中有一个中间件字段，用于确定是否使用 audit，经过测试，当 enabled:false时，无法调用npm audit，当enabled:true时，可以调用npm audit。 从这里我们可以知道，不同的 npm 仓库可以决定当前终端是否可以使用 npm audit 命令。 是否和 npm 版本有关？确定使用 npm audit 所需的版本需为 [email protected] & npm@6以及以后版本（node 版本中，并没有与 [email protected] 对应的版本，所以推荐使用 npm@6 以后的版本，也就是 Node 版本大于 10.3.0 版本） 看看不同 npm 版本使用 npm audit 的效果 Npm 5.6.0 Node版本小于 10.3.0可以看到信息来源是 nodesecurity.io/advisories 这个地址，这是 node 安全通告数据库 [email protected]可以看到信息来源是 github.com/advisories 而该仓库的漏洞来源就包括了之前的 node 安全通告数据库， 至于该仓库漏洞的其他来源可以往下看，后续会有解答 [email protected]可以看到漏洞来源也是 github.com/advisories ，且展示方式发生了改变。 关于漏洞列表首先，该漏洞列表的全名叫 - GitHub Advisory Database GitHub Advisory Database 是什么数据库About the GitHub Advisory database GitHub 为了让开发者能够轻松实现安全开发，推出了一个名为 Advisory Database 的开放安全咨询数据库，它专注于为开发者提供高质量、可操作的漏洞信息。它不仅仅为 npm 提供漏洞信息。它可以支持不同的生态 Composer (registry: packagist.org/) Erlang (registry: hex.pm/) Go (registry: pkg.go.dev/) GitHub Actions (github.com/marketplace…) Maven (registry: repo.maven.apache.org/maven2) npm (registry: www.npmjs.com/) NuGet (registry: www.nuget.org/) pip (registry: pypi.org/) pub (registry: pub.dev/packages/re…) RubyGems (registry: rubygems.org/) Rust (registry: crates.io/) 可以看到支持这些生态 GitHub Advisory Database 漏洞来源 国家漏洞数据库 机器学习和人工审查结合检测 GitHub 上公共提交中的漏洞 在 GitHub 上报告的安全公告 npm 安全通告数据库 这些漏洞谁维护的？github 内部人员， 社群 具体可以看下面readme github.com/github/advi… 这是仓库 readme，可以看到问题的所在点 有两种方法可以为该存储库中提供的信息做出贡献。 从github.com/advisories,上任何单个建议中，单击针对此漏洞的改进建议(如下所示)以打开“改进的安全建议”表单。编辑表单中的信息，然后单击“提交改进”以打开包含您建议的更改的“拉”请求。或者，您可以直接针对该存储库中的文件提交一个拉请求。为此，请遵循投稿指南。 npm audit fix修复策略 直接依赖漏洞分三种情况进行实践 不锁版本号 当前我们直接依赖了一个具有安全漏洞的 [email protected] 版本： "dependencies": { "lodash": "^4.17.4" } 运行 npm audit 查看报告可以看到给出了建议——运行 npm install [email protected] 通过安全漏洞数据库查看修复版本是 4.17.21由于 ^4.17.4 的依赖范围是 >=4.0.0 < 5.0.0 ，已修复的版本 4.17.21 在这个范围内，那么实际上 npm audit fix 执行的逻辑就是 npm update [email protected]. 21。 运行 npm audit fix，查看版本更新可以看到实际上就是升级到了 4.17.21，由此可以知道，npm audit fix 的策略就是升级到已修复版本。 但是由于4.17.21已经是 lodash 的最大版本，因此还得确定到底是该命令到底将依赖包升级到了修复版，还是最新版 继续验证确定到底是升级到修复版，还是最新版后续找到一个 lodash 4.10.0版本漏洞，4.10.11版本被修复的漏洞条目，用来测试升级版本规律，然后本地安装 lodash 4.10.0 版本，运行 npm audit fix ，发现修复后，包版本变为了4.17.21，而不是 4.10.11，由此得知，npm audit fix 的策略就是升级到最新且已修复的版本，而不是被修复的那一版。（即依赖含有漏洞版本号被修复的版本为） 锁版本号 再次通过 npm i [email protected] 安装回含漏洞版本，将当前版本锁住可以看到相比之前多了一条警告，显示这个包可能是一个breaking changes（重大更改）， 对比一下之前安装 loadsh 4.12.4 版本的 npm audit 报告 可以看到 npm audit fix 对有报警信息的条目此就无能为力了，并且会建议使用 npm audit fix --force，或者手动升级。 为了再验证是否是大版本问题导致报警，可以再使用 4.0.0版本进行尝试，因为 4.0.0就是 3.10.1 的下一个版本，且大版本已经升级到4.0.0运行 npm i [email protected] ，安装 lodash 4.0.0 版本 然后运行 npm audit fix ，发现 lodash 成功升级到 4.17.21 综上所述，可以确定，如果涉及到依赖包的大版本升级，npm audit 会出示一条报警信息，且阻止 npm audit fix 进行自动修复，并建议手动升级或运行 npm audit fix --force 间接依赖漏洞假设我们现在的依赖路径非常深：@commitlint/cli^7.1.2>@commitlint/load^1.0.1>lodash^3.0.0 因为 @commitlint/load 对 lodash 的依赖是^3.0.0(>=3.0.0 =4.0.0 |
【本文地址】
今日新闻 |
推荐新闻 |